Was watching a rather interesting talk by the Wikispeed CEO  in the SDEC 12: Keynote.

So, we might have gotten to being agile, decades after, having taken a page from manufacturing. But surely, the software practices thereafter evolved much faster than its manufacturing counterparts. Now, however, it seems like the manufacturing world  should catch up soon . The presentation above talks about a whole lot things. Their process already seems to have embraced a lot of stuff we do, some adapted -

1. They call it eXtreme Manufacturing (XM)
2. Scrum - 7 day
3. Cross-functional teams
4. Swarming
5. Feedback - Showcasing often
6. Evolutionary design - starting with ugly&working&frugal products
7. Inter-changeable/modularized parts
8. TDD! and regression suites
9. Promiscuous pairing, even!! 

Wonder if it would be an interesting intro to the many non-IT clients we might encounter in the consulting world, I suppose - especially making the non-IT stakeholders see value in some of the practices we espouse? Not sure if these attempts are unique, but the extent to which these guys have adopted seems quite impressive - and then make it work? 100 mpg? 3-hour swarmed assembly? Awesome!

Seems like they also presented in Agile 2012 in Dallas - wonder what your takeaways were, if you were there.

Here is another, shorter, talk o TED by Joe Justice.

Below are couple of sample, real and typical job descriptions of business analysts, posted on career classifieds. What strikes you about these, at a casual glance? -

1. Sr. Business Analyst in a financial publishing house - "

• Collaborate with internal and external customers, software engineers, etc. to interview, research, analyze, and derive business, functional, and non-functional requirements for products.
  
• Translate business requirements into detailed functional and non-functional specifications.
• Contribute, as required, to the "look" and "feel" of the product including screen design, on-line text, and/or graphical user interface (GUI) consistent with company standards.
• Participate in the design and testing phases, including design and testing of prototypes and orchestration and sign-off on acceptance test results to ensure design integrity"
  

2. A pure play IT Business analyst - 
"

• Lead and facilitate the elaboration process for new system projects
• Analyze and design solution recommendations for system modifications/enhancement to meet the needs of the end users.
• Develop system requirement specifications for system projects and large strategic projects
• Act as an liaison between end users and IT departments
• Develop test plans and participate in system implementation of new or revised systems"

Do you see anything missing in the above? Of course, one could argue that the description is just as that particular firm wants it to be, and every firm has its own "right" role definition.  Be that as may, and in general, even if one may  say that the definition of a BA varies across the industry, are the descriptions still complete? 

Below is my mindmap of various areas that I think every Business Analyst needs to be looking at. The third level down (Brown) may be defined in context and specific to the prevalent practices, but are not the first two levels fairly generic? If a BA is not doing these, then can the resulting software product still be good? Consistently .

What <IS> the role of a Business Analyst
Business analysis, traditionally, has included among other things the following broad objectives -
1. Ensure client requirements are all captured
2. Ensure the developer understands it

3. Ensure the code meets the aforementioned requirements

There are different schools of thought on how these are performed. In general though, traditionally,  analysis demanded these objectives be met through the following activities:
Objective: 1. Ensure client requirements are all captured
Activities:
a. Elicit requirements through Questionnaire, Workshops
b. Detailed documents or Use cases/diagrams to capture requirements
c. Traceability to ensure requirements don't get dropped

Objective 2. Ensure the developer understands it
Activities:
a. Capture system/data flows
b. Capture requirements as use cases/test cases


Objective: 3. Ensure the code meets the aforementioned requirementsActivities:
a. Perform and sign-off  functional tests

What <SHOULD BE> the role of a Business Analyst

As the role evolved, especially in the Agile world (coincidentally not consequently, I think) , business analysis has also acquired the following objectives/activities, and dropped some of the above as a result:

Objective 4. Ensure the requirements are right
Activities:
a. User stories: Get close to the end-users, and think from their perspective and their goals - look at user value, not business value - hence ensure,  the real requirements are captured -> This has received a whole new infusion of ideas from Human Computer Interaction/Cognitive and behavioural science -> this also meant use cases, which were still partly systemic rather than completely user-centric, became user stories. And then, user stories became better defined when BAs realized "users" should be real end-users, not the system. Thus, non-functional requirements  became cross-functional requirement or just plain requirements worded differently to ensure the delivery team doesn't loose focus on how the user experiences it
b. Task Analysis/Story maps: We started looking at requirements as necessary to perform a user objective. This ensured we optimize software for the best user experience, and not just add better UI or throw better hardware to take care of it. More importantly it e
c. Get user feedback: Plan to release often, showcase and get continuous feedback

Objective 5. Maximize ROI
Activities
a. Identify MMF (Minimum marketable features) - Ensure requirements are not just prioritized, but packaged in such a way that value is realized at the earliest. And minimum time is spent on what is less valuable
b. Split stories/Release planning - create independent, negotiable, valuable, estimable, small and testable chunks of requirements that will flow through the development pipeline smoothly, and can beget immediate feedback